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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 
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Scope 



The present document analyzes the issues concerned with interconnection and routeing in NGN and their imphcations 
and requirements for numbering, naming and addressing and related resolution functionalities. 

Several different interconnection scenarios are considered, based on TISPAN "NGN Functional Architecture" ([5]), 
although not all require the use of all architectural functions. The role of the transit network has also been considered in 
order to evaluate the knowledge of numbers/names served by different operators and related requirements for routing 
purposes. 

Some scenarios may require the availability of infrastructure systems for numbering/naming resolutions, such as 
infrastructure ENUM, or other database based system for route resolution, and may require coordinated provision by 
involved operators. 

The present document focuses on calls routed between subscribers identified by E.164 numbers, coded through either 
tel URI and SIP URI formats. It also applies only to the transfer of calls across interconnection points between the home 
network of the A-Party and the home network of the B -Party. It does not consider in detail interconnections needed to 
support roaming scenarios. A further issue of the present document will consider interconnect scenarios related to 
roaming. 

The present document is relevant not just to IMS but to any NGN SIP-based interconnection. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] Void. 

[2] ETSI TS 181 005: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Services and Capabilities Requirements". 



ETSI 



6 ETSI TS 1 84 006 V2.1 .1 (2008-09) 

[3] ETSI TS 182 012: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS-based PSTN/ISDN Emulation Sub-system (PES); 
Functional architecture". 

[4] ETSI ES 282 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture". 

[5] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Functional Architecture". 

[6] ETSI ES 283 018: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control: H.248 Profile for controlling 
Border Gateway Functions (BGF) in the Resource and Admission Control Subsystem (RACS); 
Protocol specification" . 

[7] ETSI ES 283 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 
[Release 7], modified]". 

[8] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 (3GPP TS 
23.228 version 7.5.0 Release 7)". 

[9] ITU-T Recommendation Q.3401: "NGN NNI Signalling Profile (Protocol Set 1)". 

[10] ETSI EN 383 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Interworking between Session Initiation Protocol (SIP) and 
Bearer Independent Call Control (BICC) Protocol or ISDN User Part (ISUP) [ITU-T 
Recommendation Q. 1912.5, modified]". 

[11] ETSI TS 123 228: "IP Multimedia Subsystem (IMS); Stage 2". 

[12] ETSI TS 124 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Signalling flows for the IP multimedia call control based 
on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 
(3GPP TS 24.228 Release 5)". 

[13] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Internet Protocol (IP) multimedia call control protocol 
based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 
(3GPP TS 24.229 Release 8)". 

[14] ETSI TS 129 163: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Interworking between the IP Multimedia (IM) Core 
Network (CN) subsystem and Circuit Switched (CS) networks (3GPP TS 29.163 Release 7)". 

[15] ETSI TS 184 002: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Identifiers (IDs) for NGN". 

[16] Void. 

[17] ITU-T Recommendation E.164: "The international public telecommunication numbering plan". 

[18] IETF RFC 3261: "SIP: Session Initiation Protocol". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 180 000: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Terminology". 
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[i.2] 



ETSI TR 184 007: "Telecommunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); Naming/Numbering Address Resolution (NAR)". 



3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3 GPP 3rd Generation Partnership Project 

BGCF Breakout Gateway Control Function 

BIGG Bearer-Independent Gall Gontrol 

GP Gommunication Provider 

DNS Domain Name System 

ENUM E. 1 64 telephone NUmber Mapping 

GRX GRPS Roaming eXchange 

GSMA GSM Association 

IBGF Interconnection Border Gontrol Function 

I-GSGF Interrogating-Gall/Session Gontrol Function 

I-ENUM Infrastructure ENUM 

IETF Internet Engineering Task Force 

IMS IP Multimedia System 

IPX IP Packet eXchange 

ISUP ISDN Signalling User Part 

IWF InterWorking Function 

MGGF Media Gateway Gontrol Function 

NAR Naming/Numbering Addressing Resolution 

NGN Next generation Network 

NNI Network to Network Interface 

OPID Originating Party IDentity 

P-GSGF Proxy-Gall/Session Gontrol Function 

PES PSTN Emulation Service 

PSTN PubHc Switched Telephone Network 

RAGS Resource and Admission Gontrol Subsystem 

S-GSGF Serving-Gall/Session Gontrol Function 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

TPID Terminating Party IDentity 

UA User Agent 

URI Uniform Resource Identifier 



Introduction 



This Technical Specification: 

• Defines a Routeing Model for NGN Interconnection. 

• Proposes the first set of Requirements and related GP Routeing Roles. 

• Defines the resolution process for tel URI and SIP URI. 

• Proposes the possible basic structure of NAR [i.2] Interconnect Framework. 
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Routeing Model for NGN Interconnection 



5.1 



Reference scheme for interconnection 



Figure 1 describes the NGN layers and the reference scheme for interconnection in NGN. The routeing resolution in 
NGN includes both the typical IP interworking routeing rules that are bounded into the transport layer and the 
service/control layer ones. 
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Figure 1 : Reference scheme for Interconnection and routeing 

The call control and service control functions take into account service capabilities requirements for routeing. Some 
applications entities (for instance redirect servers and/or location application) may also be required to define the route. 
For the purpose of interconnection the Call Control function has to resolve routeing in order to get the next hop and 
reach the required destination (the transport layer has to allocate the resource required based on the services 
characteristics). As a consequence, the NGN routeing determination process includes both service and transport 
functions to define the correct destination and requires an appropriate service transport resources allocation at the 
interconnection level. 

The functionalities used for routeing at the transport layer follow the existing IP intrinsic routeing mechanisms, and 
have also to satisfy the NGN service requirements and the transport resource requirements (RACS function [4], [5]). 
Therefore routeing resolution at transport layer is outside the scope of the present document. 

The destination number/name and the type of service required are essential to identify the route for service layer 
routeing. The ETSI standards on NGN public identity [15] state that E.164 numbering is the main customer 
identification scheme. However in addition domain name based identifiers can be also used. 

In the case of the SIP protocol, as defined in relevant ETSI standards ([7]), such public identifiers are carried through 
so-called SIP URI (i.e. SIP URI: <E.164 number>@<home network domain>) and tel URI (i.e. tel URI: <E.164 
number>). 

Public identifiers resolution is an essential part of the routeing process to determine the next hop network entity for the 
session setup: this entity can either be identified by an intermediate URI translated into an appropriate IP address using 
DNS functionality, or directly mapped to an IP address. 



5.2 Interconnection and Routeing 



The innovative approach for NGN routeing requires identifying a common routeing model that guarantees 
interoperability between networks; besides more networks, provided by different operators, can be involved in session 
setup and routeing process and related decisions depends on its specific role within the session setup process 
(i.e. originating, transit, triggering, termination or interworking). 

The routeing model for interconnection should take in account required type of service and existing interconnection 
bilateral agreements in order to resolve the route. 
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Figure 2: Functional framework for routeing and CP roles 

Figure 2 identifies the essential Communication Providers' (CP) routeing roles for the routeing process of a generic 
session setup established for two users. The user A sends a service request to the NGN call control of the originating CP 
that has the objectives of processing the request and putting through the communication to other CPs or/and the user B. 

An individual CP may assume different roles on defining the route of the session for a service request and it can apply 
particular routeing procedures related also to the knowledge of the service required and the partial or full information on 
the final destination to reach (i.e. external routeing). 

The same representation can be also be adopted to include the cases where the same CP fulfils all the routeing roles for 
an internal call/session started and terminated on the same CP's domain/domains (i.e. internal routeing). 

The CP can implement one or more routeing roles at the same time, and can also provide these capabilities for other 
CPs (e.g. in the case of hosting). 

A description of the basic routeing roles follows: 

• Originating Role: responsible for the communication service offered to the end customer and basic service 
request and related call/session handling. It is influenced by the Originating customer profile. 

• Triggering Role: Responsible for numbering resolution, routeing determination toward final destination and 
the choice of appropriate next hop entity (internal or external) to reach it; additionally it is in charge to identify 
specific interworking requirements for NGN (IMS or not IMS networks) or for PSTN/ISDN interoperability. 

• The numbering resolution process implies the determination of "routable SIP URI" that includes the domain 
associated to operator which called user is subscribed to. In the case of terminating calls toward legacy 
networks (i.e. PSTN/ISDN or PLMN) the numbering resolution output can be a tel URI. 

• Terminating Role: responsible for terminating and serving the session-oriented communication to end user. 



5.3 Transit capabilities 



In addition to the previous basic CPs' roles the case where one or more transit networks are involved is relevant. 

• Transit Role: Route the session-oriented communication request to the next hop CP without any SIP URI or 
tel URI mapping in routable SIP URI. All the session related information is carried on to next hop 
transparently. 

The routeing process for transit is limited to transparently deliver the session setup to the appropriate next hop CP 
(without numbering resolution or mapping in a routable SIP URI). However the transit routeing process has to 
guarantee appropriate transport resources allocation to preserve service requirements. 
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5.4 Example of complete set of CP's roles 

Figure 3 points out an example of a complete set of CP's roles for Soix Interconnection (see Soix in the NGN 
Architecture [5]) that highlights different application of routeing model for route determination. 



9 Signalling Control functionalities 
— ■ — ► Service/Control layer signalling 




Transport layer 

Figure 3: CPs roles for routeing process for Soix interconnection 

Following is the routeing process implementation among different CPs, and the description of guidelines for 
implementations : 

• Originating role, on the basis of service required by session-based originated by Originating user, forwards the 
session setup request for routeing analysis to the Triggering Role entity, which is provided internally or by a 
different CP on the basis of bilateral agreements. 

• Triggering role is per definition responsible for resolving public user identities to determine the next hop 
outbound route towards the operator to which the destination user is subscribed. 

• Transit role is assumed by a CP that, on the basis of bilateral agreements, transparently forwards the session 
setup request to the appropriate next hop CP. 

• Terminating role is responsible for delivering communication service session setup to the destination end user; 
the numbering/naming analysis and related routeing process is limited to internal identification of session 
control entity associated to end user for required service communication session setup and then to 
determination of the IP address associated to the user terminal equipment. Where a Routable SIP URI is used, 
the CP with the terminating role for a service communication session is identified through the domain part of 
the routable SIP URI. 
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5.5 Routeing process requirements and related CP roles 

At least the following parameters and functional elements shall be available as input of NGN Routeing Model 
(see figure 4): 

• Service parameters: set of parameters that represents service requirement for a specific session setup. 

• Terminating Party Identity (TPID): it is an E.164 number in tel URI or SIP URI coding format; optionally a 
domain name identifier can be also used. 

• Originating Party Identity (OPID): is an E.164 number in tel URI or SIP URI coding format; optionally a 
domain name identifier can be also used. 

• Performance parameters: That parameter can be taken into account for defining special action on routeing 
(i.e. bearer resources allocation, requirements on possible route, congestion and/or unavailable resources, etc.). 

It is also relevant to include the case of route determination for the case of overlap signalling (see [7]) in which a partial 
routeing decision can be made before dialling is completed. 

At least the following parameters and functional elements shall be available as output of NGN Routeing Model (see 
figure 4): 

• SIP URI or tel URI identifying the destination user. 

• Next Hop ID: it identifies the network entity (i.e. border gateway or other signalling/control functionality) that 
enables or is in charge of reaching next hop CP. 

• Transport resource parameters: parameters meaningful for transport addressing and routeing process at 
transport layer for resource allocation. 

The SIP URI that it is obtained through the numbering/naming resolution process is called a routable SIP URI since its 
domain part identifies the appropriate terminating CP. 
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requirements 
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-► If external routeing: 

■ Next Hop border gateway (naming or IP 
addressing) 

■ Routing policy (i.e. load sharing, etc.) 

■ OPID 

■ TPID 

■ telURI,SIP URI or routable SIP URI 

■ Other service dependent characterizations 

■ Etc 



-► ■ NextHop Node or Gateway for transport 
layer 

■ Originating and destination IP address 

■ IP internetworking routing policy 



Figure 4: Common general purpose Routeing Model for NGN 
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Considering figure 4, the common requirements for the routeing model are the following: 

• Numbering and naming resolution functionality are applied for routable SIP URI determination, based on 
specific mapping functionalities (database with relation with numbering/naming and destination CPs, etc.). 

• The routeing process shall depend on the service characteristics and associated parameters that are meaningful 
for determination of the route to the destination network. The process shall check and validate the service 
requirements compatibility with user service profile and network resource availability. 

• Originating and Terminating Party Public Identities shall be considered the essential information for routeing 
process. 

• Other service dependent parameters (for instance location parameters) can be considered if meaningful for 
routeing process application. 

Considering the different roles identified for routeing in figure 3, the routeing model for NGN will be appropriately 
characterized to apply associated functionalities and input/output parameters. 

Table 1 : Requirements and actions for CP roles 



CP roles 


Requirement and actions summing up 


Originating 


TPID is not resolved by CP's call control. 

Service session setup request has to be forwarded to Transit or Triggering CP. 


Triggering 


tel URI or SIP URI is resolved in a "routable" SIP URI. 


Triggering for 
interworking 


tel URI or SIP URI can not be resolved, since final destination is PSTN/ISDN or PLMN or an 

"All IP" network not compliant with ETSI NGN specifications. 

tel URI is forwarded to interworking function to apply specific resolution mechanisms and 

procedures. 


Terminating 


The domain part of the routable SIP URI corresponds to the domain of the terminating CP and 
end user shall be identified. 


Transit 


Call/session is to be delivered transparently to a terminating CP, basing on a tel URI or a 

Routable SIP URI domain part different from the transit CP. 

tel URI or SIP URI, after having identified routing towards terminating CP, is passed on 

unmodified. 



5.6 SIP and E.164 numbering 



Also at interconnection [i.2] applies and table 2 shows the relationship between the Public ID that identifies a 
Terminating and Originating user parties and the formats used in SIP header fields. The present document is focused on 
E.164 numbering in tel URI or SIP URI coding formats. 

Table 2: Public IDs and formats 





Public ID (User parties) 


NGN coding formats 


User/Service Identifiers 


"User@Domain" format 


SIP URI 


International or national E.164 
Numbers 


tel URI 
SIP URI 



Thus the two formats that may be used are: 

• tel URI for international or national numbers, e.g. tel: +431505641636. 

• SIP URI, e.g. sip: +43 1505641 636 @<serving operator>;user=phone. 

NOTE: "user=phone" is appended where the user part of the SIP URI is a string that is the same as a tel URI. 

Additionally, the SIP "phone-context" parameter is used in case of national E.164 numbers and other digit 
strings that are non-E.164 numbers. 
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5.7 Address Resolution, Routeing requirements 

Address resolution function can be logically divided in two general phases: 

• Number to naming mapping: where the number is converted to a format which can be used by the name 
resolution function. 

• Naming resolution: where the internal domain naming, looking up in an infrastructure ENUM or in equivalent 
database or static table, to retrieve "Routeable" SIP URI (that contains the serving operator domain). 

If number or name can not be solved locally, address resolution function passes number on, towards a pre-configured 
triggering internal entity or different CP network, using tel URI format. 

When the number/name has been resolved, the Routeable SIP URI is used to derive the IP address of next functional 
entity, generally basing on DNS mechanisms or on local naming-address mapping table functionalities. 

Figure 5 illustrates such a resolution process that is required for number and naming translations from the dial string to 
the IP address, associated to the next hop functional entity. 



Hostname 



Dial String 



Process 
Dialed Digits 



E.164 



Target Name 

( tel URI, SIP URI, URN) 



Name/Number to SIP 
URI Translation 



SIPURI ■► 



Target Routable SIP URI 



Route Determination & 
Selection 



Target Home Operator/CP 



Address Resolution 



Target Network Element / User IP-Address 
Figure 5: Naming/Numbering Address Resolution overview (for details see [i.2] clause 6.3) 
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It should be noted that ENUM can provide only the domain of the home CP for the B -party or terminating CP. On the 
basis of such domain information, the internal routeing functions, have to define the next hop entity or border gateway 
to handle call/session and/or the transit role CP, on the base of specific routeing arrangement defined by CPs (e.g. on 
the base of bilateral agreements). 

NOTE: Generally, in alignment with ETSI/3GPP specifications, the presence of an E.164 number in a specific 
infrastructure ENUM assures that associated terminating/serving CP is reachable through pre-defined 
interconnection arrangements and related networks interconnection; for instance, that is the case of IPX 
(GRX successor), and internal carrier ENUM infrastructures managed by GSMA and related to the fixed- 
mobile international interconnection context. 

The following rules for SIP header coding apply: 

1) The called/terminating user identity is inserted in the TO field. 

2) The Request-URI field content shall be, when available, a "Routeable" SIP URI that is a SIP URI with domain 
part identifying terminating/serving CP determined from an authoritative source or locally pre-defined. 
Otherwise Request-URI field content shall be E.164 number coded by tel URI format. The number in the tel 
URI coding format can be in national or international E.164 number format, in accordance with ITU-T 
Recommendation E.164 [17]. 

3) Route header field contains the next hop(s). 

The above is based on figure 6 which is derived from analysis of various parts of RFC 3261 [18]. 
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Figure 6: header handling in SIP 

5.7.1 tel URI and SIP URI resolution requirements and procedures 

Figure 7 describes a general process and related functions for tel URI and SIP URI, provided by the user (Dialling) or in 
interconnection scenarios, based on ENUM systems or other translation database functions. 

The flow shows the potential usage of infrastructure ENUM (if available) or of other DBs in order to define the correct 
route towards both local network terminations and out-bound interconnected network and CPs. 

Note that, in figure 7, the local Number Analysis function (NAR) is used to handle cases where I-ENUM fails to find 
the number and associated NAPTR record and to find out the appropriate destination which delivers the call/session to; 
that could be the situation in which dialled number is not present in ENUM or the derived SIP URI domain part is not 
recognized locally as a reachable CP. 

The general outputs of figure 7 procedures and functions are the following: 

• if the resolution of tel URI or SIP URI has succeeded, then the session is delivered to the customer network 
termination point or the "Routable" SIP URI is passed on to the interconnected CP; 

• if the resolution has not succeeded, then analysis functions will check if it is a circuit- switched PSTN/ISDN or 
PLMN destination or other "All IP" networks not integrated with NGN environment or reachable by other 
interconnected CPs, in which case a tel URI or SIP URI will be provided to for routeing resolution. 
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Figure 7: General functions and procedures for tel URI and SIP URI resolution in NGN 
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5.8 Relation with NAR Interconnection general framework 

The gap analysis based on NAR [i.2] use cases has identified a requirement to introduce NAR functionality in ETSI 
NGN architecture. The present document provides further definition of NAR functionality for NGN Interconnection 
routeing. NAR for Interconnection and routeing is concentrated in the control and service layers which are responsible 
for handling numbering, naming and routing tasks and driving lower layer requirements (e.g. transport entities). 

NAR does not correspond either to new entities or new specific reference points. Instead there is a need to focus on a 
homogeneous description that addresses these specific needs of NGN interconnection and routeing. Because the NAR 
functionality is the context aware resolution of an identifier into a result which is useable for NGN routeing, it shall 
include also the interconnection and routeing requirements. 

Figure 8 describes, on the basis of [4], the specific NAR functionality applied to the interconnection and routeing 
entities that can consist in general of one or more relations with service/control layers entities. 



User Equipment 



Applications ^ 



NAR 
functionality 



Service Layer 



User 
profile^' 



Other 
subsystems 



Core IIVIS 



PSTN/ISDN 

Emulation 

subsystem 



Network 
Attachment 
Subsystem 




Resource and 

Admission Control 

Subsystem 



Transport Layer 



Transfer Functions 



Other networks 



Figure 8: NAR functionality in ETSI NGN arcliitecture for interconnection 

6 Interconnection, interworking, interface and routeing 

requirements 

Interconnection refers to the connection of two networks so that they can support interoperable services. There could be 
pure transport IP connectivity interconnection, either with "best effort" or with specific QoS classes, or "service-aware" 
interconnection for multimedia and innovative "session-based" services. 

Interconnection takes place at a reference point at which a specific Network to Network Interface (NNI) is defined, 
generally related to different end-to-end interoperable offered service. The characteristics of the NNI depend on the 
kind of networks / administrative domains to be interconnected, for instance IMS, PSTN/ISDN, and PLMN, other 
IP-based networks, etc. 
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In general two different networks are interconnected by session border functionalities, often located in specific border 
equipments in which any necessary interworking functionalities (for instance, the conversion from one protocol to 
another) are provided. That allows separating the two networks like two different domains, in order to manage them 
independently. 

Thus for successful interconnection definition, there is a need to identify at least: 

• Interconnection service required, i.e. pure IP connectivity or "session-based" voice/multimedia service. 

• NNI Interface requirement for specification, also for rules between the signalling and transmission control on 
each side of the session border functionalities or interworking function 

As a reference scheme figure 9 shall be considered. 
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Figure 9: Reference scheme for NNI Interconnection between two networks 



6.1 



Interconnection NNI in IMS and NGN architecture 



Figure 10, which is based on the relevant ETSI standards and specifications [4] and [5], provides an overview of 
different possible NNIs. Clause 5 of the present document, which describes the routeing model for interconnection, 
covers the following types of service interconnections: 

• "basic end-to-end service interconnection" for the routeing and setting up of a call/session between two NGN 
domains and related end users; 

• "Roaming end-to-end interconnection" to support a call originated from a roaming (visited) network or a call 
extended from the B -party serving (home) network to the roaming (visited) network. However this case is out 
scope of the present document. 

The following possible locations of NNIs are also considered to be in the scope of the present document (excluding 
internal interfaces because they are not interconnection points towards other networks): 

1) Signalling and transport NNI between IMS networks in different administrative domains. 

2) Signalling and transport NNI between IMS network and other Non IMS IP networks. 

Although the general NGN routeing model can be adapted to include transport layer interconnection scenarios described 
in the NGN general architecture [4], they are outside the scope of the present document which relates only to end-to-end 
service interconnection. 
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Figure 10: NNI possibilities based on [4], and [5] 



6.2 



Transit network scenarios 



The term transit refers to the routeing of calls and other communications through networks other than the originating 
and terminating ones. 

There are essentially two general categories of NGN transit networks: 

• "IP Connectivity only" transit network, where IP packets traffic is delivered by transit network without any 
knowledge of the carried service. This is referred to as Coix Interconnection. 

• "Service related" transit network, where the transit network interacts with the communications at the service 
control level for end-to-end service interoperability. This is referred to as Soix Interconnection. 

Every network provides at least some connectivity but may or may not provide service related transit. The proxy 
functions needed for service related transit may be provided by a third party on a connectivity platform. 

Some options are illustrated in figure 1 1 . 
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Figure 1 1 : Examples of different transit network scenarios 

There are two main types of platforms providing IP-level connectivity: 

a) Dedicated "telco type" networks (e.g. via IPX which can be viewed as an extranet). 

b) The public Internet. 

Note also that transit level functionality may be provided on a hop-by-hop basis across multiple networks that each run 
their own service related transit function. 

Figure 12 illustrates Soix interconnection where the transit network does interact with the signalling. 
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Figure 12: Solx-to-SoIx Transit Interconnection 

In this figure, end-to-end service interoperability can be guaranteed by the Transit Domain as a result of SoIx 
interconnection on both sides. End-to-end service requirements are delivered by all interconnected networks through the 
control of transport resources via the RACS functions. 
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6.3 Application to different NGN scenarios 

Table 3 shows the appHcation of NGN scenarios, based on an "IP-based, session-based" NNI and related 
naming/numbering requirements. Starting from ETSI NGN architectures and related subsystems (i.e. PES, IMS, etc.) 
and considering concrete "IP-based" NNI "session-based" interconnection scenarios, a limited number of cases can be 
identified. 

Table 3: Main interconnection scenarios, protocols and related numbering/naming requirements 



"IP-based" session-based 
interconnection scenario 


ETSI NNI 

signalling 

protocol 


NNI transport 

(control and user 

plane) 


Naming/numbering requirements 


NGN (CS domain)^NGN (CS 
domain) 


SIP-I 


IP-based 


E.164 number or tel URI 

(in case of SIP URI the user part is the key 

for routeing. The domain part could be 

used for media gateway selection) 


NGN (PS domain)^NGN (PS 
domain) 


SIP 


IP-based 


tel URI or SIP URI 


NGN (PS domain)^NGN (CS 
domain) 


SIP-I or SIP 


IP-based 


E.164 number, tel URI or SIP URI 


NGN^ other IP network 


SIP 


IP-based 


SIP URI 


NGN^PSTN/ISDN/PLMN 


ISUP/BICC 


SS7 and TDM 


E.164 number 



Note that in the table above, the term "CS domain" means that the control plane is NGN subsystem (IMS, PES) and the 
user plane or bearer is based on circuit switch technology. 

Figure 13 describes the interworking of NGN with PSTN/ISDN and Other IP Network (that has been defined into [5]) 
that are described into the last two lines of table 3. 




Figure 13: Network interconnection at transport layer [5] 

The following conclusions can be drawn: 

• NNI definitions should not depend on the specific NGN subsystem involved, since it is a fundamental 
objective to converge toward strictly limited NNI interfaces and protocols that cover all possible scenarios. 

• NGN must be able to support interworking with circuit-switched networks. 
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Annex A (informative): 

Protocols at the NNI points and interworking 

The signalling NNI protocol used for IMS interconnection is SIP and both ETSI and ITU-T Recommendation 
Q.3401 [9] (NNI for voice band services) have made adaptations of SIP, defined by IETF in RFC 3261 [18], for 
different network applications. 

Interconnection between networks adherent to different versions of the SIP standard can require an interworking 
function. The main different SIP standards are the following: 

• The ITU-T profile for the pure SIP NNI specified in ITU-T Recommendation Q.3401 [9]. 

• The ITU-T Recommendation Q. 19 12.5 "Interworking between Session Initiation Protocol (SIP) and Bearer 
Independent Call Control protocol or ISDN User Part" [10]. ITU-T Recommendation Q.1912.5 [10] adapts 
and references RFC 3261 [18] for interworking with BICC/ISUP networks. 

• The 3GPP pure SIP IMS call control documents: 

TS 123 228 [11] Stage 2 which gives the main signalling flows for the IMS core network. 

TS 124 228 [12] Stage 3 signalling flows which gives example signalling flows for the IMS call control 
and expands on the information in TS 123 228 [11]. 

TS 124 229 [13 ] Stage 3 protocol which specifies the IMS call control protocol using SIP and SDP for 
the IMS core network. TS 124 229 [13] makes is an endorsement/modification of RFC 3261 [18] and 
other RFCs. 

TS 129 163 [14] Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and 
Circuit Switched (CS) networks, based on ITU-T Recommendation Q.1912.5 [10]; 

• The TISPAN pure SIP IMS call control document: 

ES 283 003 [7] which modifies and endorses TS 124 229 [13]. 

Figure A.l shows the development from the base SIP specification of the three different forms of SIP used for NNIs, 
i.e. SIP-I, IMS SIP, and non-IMS pure SIP. 
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Figure A.1 : Development of SIP variants for NNIs 



Figure A. 2 shows the development of the interworking specifications that relate the different forms of SIP to ISUP and 
BICC. The figure again shows SIP-I, the IMS SIP, and the non-IMS pure SIP. 
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Figure A.2: Development of SIP interworking specifications 
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Annex B (informative): 

SIP Header Fields at the NNI relevant to routing and 

identification 

The critical SIP element from a routeing point of view is the INVITE method. An example of an INVITE method is 
shown in figure B.l. It is a text string, and consists of: 

• The word INVITE followed by either a tel URI or a SIP URI, which may be followed by one or more 
parameters. 

• A number of subsequent lines called headers, where each line starts with a pre-defined word and is followed 
by one or more header fields. 

Each header field may contain one or more parameters. 

These terms are shown in figure B.l. 



(0 

■o 

(0 





Session Initiation Protocol 
Request-Line: 

INVITE sip:+41454000191@cp-domain;user=phone SIP/2.0 
Message Header 
/T To: <sip: +41454000191@cp-domain;user=phone> 

From: "Name" <sip: +41454000201@cp-domain; transport=udp> ; tag= <?> 

Call-ID: <?> 

CSeq: 1 INVITE 

Max- Forwards : 6 8 

Content -Length: 343 

Via: SIP/2. 0/UDP 123.45.123.48 : 5060 ; branch= <?> 

Via: SIP/2. 0/UDP 123 . 45 . 123 . 150 : 5060 ; branch= <?> 

Via: SIP/2 .0/UDP 192 .168.1.36 :2725; 

received=10 .7.7. 149;branch= <?>; 

rport=56608 

Route : <sip : scscf 1 . intranet .net : 6050 ; lr> 

Record-Route: <sip: <?>cp-domain@scscf 1 . intranet . net : 6050 ; 

maddr=12 3 .45.123.48;lr> 
Contact: <sip:+41454000201@123 .45. 123. 150: 50 60; transport=udp> ; 
f low-id=l 

Content-Type: application/sdp 
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, 

NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO 
Allow-Events : talk 
Allow-Events : hold 
Allow-Events : refer 
Accept: application/sdp 
Supported: lOOrel, replaces 
P-Asserted- Identity : "Name" 
User-Agent: snom320/SC0825 
P- Charging -Vector: icid-value=<?> 
Session-Expires: 360 
Min-SE: 360 
P-Key-Flags: keys="3" 
Message body 

Session Description Protocol 

Session Description Protocol Version (v) : 

Owner/Creator, Session Id (o) : root xx yy IN IP4 10.1.1.14S 
Session Name (s) : call 

Connection Information (c) : IN IP4 123.45.123.85 
Time Description, active time (t) : 
Media Description, name and address (m) : 
audio 14734 RTP/AVP 18 



callerid 

sip:+414 54 0201@cp-domain> 



V 



Media Attribute (a) 

Media Attribute (a) 

Media Attribute (a) 

Media Attribute (a) 

Media Attribute (a) 

Media Attribute (a) 

Media Attribute (a) 

Media Attribute (a) 

Media Attribute (a) 

Media Attribute (a) 



3 9 2 3 4 101 
rtpmap:18 g729/8000 
rtpmap:8 pcma/8 00 
rtpmap:9 g722/800 
rtpmap:2 g726-32/8000 
rtpmap:3 gsm/8 00 
rtpmap:4 g723/800 
rtpmap:101 telephone -event/ 80 
fmtp:101 0-16 
ptime : 2 
sendrecv 



Figure B.1 : Structure of the INVITE Message 
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The specification of SIP protocol is defined in ES 283 003 [7]. The following explains the main header fields relevant to 
routing and identification as used in TISPAN. 

NOTE 1: Some of these uses are more restrictive than are specified in RFC 3261 [18]. 

• Request-URI 

The Request-URI field identifies the incoming call server (the I-CSCF in the case of IMS) of the serving 
network. A proxy can only change the Request-URI of a request during forwarding if it is responsible for that 
URL 

• VIA 

The VIA header field(s) keeps track of all the proxies a request has traversed. The response uses these VIA(s) 
to be routed back via the same proxies as traversed by the request. The VIA header is mandatory in all SIP 
messages, and as a minimum lists the involved UAs. 

If the host portion of the "sent-by" parameter contains a domain name, or if it contains an IP address that 
differs from the packet source address, the server must add a "received" parameter to that VIA header field 
value. This parameter must contain the source address from which the packet was received. (This is to assist 
the server transport layer in sending the response, since it must be sent to the source IP address from which the 
request came.) 

Consider a request received by the server transport which looks like, in part: 

INVITE sip:bob@Biloxi .com SIP/2.0 

Via: SIP/2. 0/UDP bobspc.biloxi .com: 5060 

The request is received with a source IP address of 192.0.2.4. Before passing the request up, the transport adds 
a "received" parameter, so that the request would look like, in part: 

INVITE sip:bob@Biloxi .com SIP/2.0 

Via: SIP/2 . 0/UDP bobspc.biloxi .com: 5060; received=192 . . 2 . 4 

• Contact 

Contact headers are exchanged in order to let peer UAs exchange SIP signalling directly with no 
intermediaries. This applies except for the proxies that have explicitly requested to remain in the signalling 
path by adding their URI in a previous Record-Route. 

• Record-Route 

The header is added by a Proxy during a transaction in order for the Proxy to remain in the path for all requests 
sent within the dialog. The set of all recorded routes are carried in the response to this request. Route headers 
are added by the initiator in subsequent transactions to enforce the routing as recorded by the Record-Routes 
The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to be 
routed through the proxy. 

• Route 

Enforces the routing as recorded in a previous transaction by applying Record-Routes. 

• P-Called-Party-ID 

Identifies which of the several possible identities an INVITE is addressed to. 

• To 

This header is used for UA-UA purposes and so should be passed unchanged and unused by transit networks. 

NOTE 2: This header is used by the networks in the REGISTER process. 

NOTE 3: The "tag" parameter is used in the To and From header fields of SIP messages. It serves as a general 

mechanism to identify a dialog, which is the combination of the Call-ID along with two tags, one from 
each participant in the dialog. 
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Call-ID: 



The Call-ID header field acts as a unique identifier to group together a series of messages. It shall be the same 
for all requests and responses sent by either UA in a dialog. It should be the same in each registration from a 

UA. 

Branch: 

The Via header field value shall contain a branch parameter. This parameter is used to identify the transaction 
created by that request. This parameter is used by both the client and the server. The branch parameter value 
shall be unique across space and time for all requests sent by the UA. 
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